Add new section 'Supporting a new SoC' #99
Conversation
There was a problem hiding this comment.
this is a random passing-by review, i don't have a stake in this but saw it and was positively surprised by it!
one thing i'm wondering: it seems that a lot of HAL activity is now centered around embassy (with the exception of e.g. esp-hal). i'm wondering if this should be explicitly pointed out so that vendors could opt to implement their PACs & HALs directly in embassy rather than having them separate? OTOH embassy is not a WG project, thus this might be the wrong place for this?
| recommend reaching out to the Embedded Rust Working Group (REWG) leads. They | ||
| can provide valuable insights and support to help you navigate the process | ||
| effectively. | ||
|
|
There was a problem hiding this comment.
i think step 0 is missing: support for the target architecture in LLVM (and step 0b: rustc using an LLVM version which contains said support).
the alternative is the manufacturer maintaining an LLVM & rustc fork (until things get upstreamed, anyway), see what espressif is doing with espup for the xtensa arch.
There was a problem hiding this comment.
This would fit in a new section I am still working, which a suggested overall flow. This was an idea from @diondokter and @jamesmunns mentioned the How do I add support for a new microcontroller to embassy? he wrote in Embassy documentation.
This is not required by embassy, and vendors typically prefer to keep their codebases in their own org/repo so they can control access to them, there's no doubts about ownership, etc. Also: maybe ask dirbaio before you start suggesting that everyone shove their code in his project's repo? |
sorry, this wasn't meant as a "hey, everyone should be doing this!" and more as a "is it the idea that this could/should be done?". sorry if that didn't come across like that CC @Dirbaio |
|
This looks great to me, thanks for updating. |
No description provided.